Layer 7 Models

How DHCP clients process incoming packets

When a DHCP client device receives a packet:

• It drops the packet if (any):
  • The packet is not a valid DHCP packet.
  • The packet's destination MAC address does not match its own MAC address.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is a DHCP-OFFER packet, it uses the information in the packet (including client IP address, offered IP address, server IP address, and gateway address) to construct a DHCP-REQUEST packet and sends it back to the server.
  • If the packet is a DHCP-ACK packet, it gets the IP address, subnet mask, and the gateway IP address from the packet and sets its IP address configuration accordingly.
  • If the packet is not a DHCP-OFFER or a DHCP-ACK packet, it will drop the packet.

How DHCP servers process incoming packets

When a DHCP server device receives a packet:

• It drops the packet if:
  • The packet is not a valid DHCP packet.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is a DHCP-DISCOVER packet:
  • If the client already has a lease:
  • Send a DHCP-OFFER packet with the associated IP to the client.
  • If the client does not already have a lease:
  • If there is an available IP address:
  • Send a DHCP-OFFER packet with the available IP address to the client.
  • Otherwise, drop the packet and stop.
  • If the packet is a DHCP-REQUEST packet:
  • If the requested IP address is available:
  • Send a DHCP-ACK packet with the available IP address to the client.
  • Bind the client to the IP address.
  • Otherwise, drop the packet and stop.
  • If the packet is a DHCP-RELEASE packet:
  • If the client is bound to the IP address:
  • Unbind the IP address and the client.
  • Otherwise, drop the packet and stop.
  • If the packet is a DHCP-OFFER or a DHCP-ACK packet, drop the packet.

How DHCP for IPv6 clients process incoming packets

When a DHCP for IPv6 client device receives a packet (flowchart here):

• It drops the packet if (any):
  • The packet is a Solicit message.
  • The packet is an Advertise message that meets any of the following conditions:
    • The message does not include a Server Identifier option.
    • The message does not include a Client Identifier option.
    • The content of the Client Identifier option does not match the client’s DUID.
    • The “transaction-id” field does not match the value the client used in its Solicit message.
  • The packet is a Request message.
  • The packet is a Reply message that meets any of the following conditions:
    • The message does not include a Server Identifier option.
    • The “transaction-id” field does not match the value used in the original message.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is an Advertise message, it will do the following actions:
    • It terminates retransmission of its Solicit message.
    • It sends a Request message to the DHCP server that the Advertise message was sent from.
  • If the packet is a Reply message, it gets the prefix and prefix length from the message and combines with its received interface’s local link address to create an IPv6 address and subnet mask.  It also retrieves the gateway IPv6 address from the packet.  Then the client sets its IPv6 address configuration accordingly.  

How DHCP for IPv6 servers process incoming packets

When a DHCP for IPv6 server device receives a packet (flowchart here):

• It drops the packet if:
  • The packet is a Solicit message that meets any of the following conditions:
    • The message does not include a Client Identifier option.
    • The message does not include a Server Identifier option.
  • The packet is an Advertise message.
  • The packet is a Request message that meets any of the following conditions:
    • The message does not include a Server Identifier option
    • The content of the Server Identifier option does not match the server’s DUID.
    • The message does not include a Client Identifier option.
  • The packet is a Reply message.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is a Solicit message, it uses the information in the packet and its server configuration to construct an Advertise message and sends it back to the client.
  • If the packet is a Request message, it uses the information in the packet and its prefix pool configuration to construct a Reply message and sends it back to the client.

How TELNET client processes work

• TELetype NETwork is a network protocol that utilizes TCP/IP protocol stack to establish a client/server connection. The user starts a TELNET client process on a PC or a Cisco device using telnet command with server IP address. The TELNET server usually listens on TCP port 23 and awaits client connection requests. A TELNET packet is generated from the client process when a key is pressed.

When a TELNET client receives a packet (flowchart here):

• If the packet is not a valid TELNET packet, it drops the packet.
• Otherwise, it writes the received information stored in the packet onto the screen.

How TELNET server processes work

• TELetype NETwork is a network protocol that utilizes TCP/IP protocol stack to establish a client/server connection. The user starts a TELNET client process on a PC or a Cisco device using telnet command with server IP address. The TELNET server is started automatically on a Cisco router or switch. The server listens on TCP port 23 awaiting client connection requests.

When a TELNET server receives a packet (flowchart here):

• If the packet is not a valid TELNET packet, it drops the packet.
• Otherwise, it checks the packet and:
  • If the information received is part of a command, it sends an echo back to the client.
  • If the server is able to determine the command entered by the client, it sends the result back to the client.
  • If the server does not understand the information received, it sends an error message back to the client.

How SSH client processes work

• SSH client utilizes TCP/IP protocol stack to establish a client/server connection.
• Before a SSH connection could be established between client and server, both need to have an RSA key pairs generated, if the keys are not generated connection will be refused by the other side.
• In order for the Cisco device to generate RSA keys it needs to be configured with hostname and IP domain name.
• The user starts a SSH client process on a PC or a router using “ssh –l” (-l is for login) command with the associated client’s user name which is already configured on the SSH server, and IP address of the SSH server. The SSH server, usually listens on TCP port 22, awaits client connection requests. A SSH packet is generated from the client process when a key is pressed.

When a SSH client receives a packet:

• If the packet is not a valid SSH packet, it drops the packet.
• Otherwise, it writes the received the information stored in the packet onto the screen.

How SSH server processes work

• SSH is a network protocol that utilizes TCP/IP protocol stack and RSA key pairs to establish a secure client/server connection. The user starts a SSH client process on a PC or a Cisco device using ssh –l command with client’s associated user name and also the server’s IP address. The SSH server is started automatically on a Cisco router. The server listens on TCP port 22 awaiting client connection requests.

When a SSH server receives a packet:

• If the packet is not a valid SSH packet it drops the packet.
• If both client and server are not configured with RSA keys the connection will be refused by SSH server.
• Otherwise, it checks the packet and:
  • If the username received in the connection request packet is configured on the server it will prompt the client for the password
    • Client will be prompted for the correct password up to 3 times. If the password that the client provides is not valid for the third time it will be disconnected by the server.
  • If the information received is part of a command, it sends an echo back to the client.
  • If the server is able to determine the command entered by the client, it sends the result back to the client.
  • If the server does not understand the information received, it sends an error message back to the client.

How DNS works

When DNS client needs to find the IP address of a domain name:

• If the DNS client is enabled on the client:
  • If DNS client finds the IP address of the domain in its cache it resolves the domain address.
  • DNS client constructs a query with the domain name and sends the query through a DNS resolver to:
    • If the client is configured with a valid DNS server address, it constructs a query with a unicast address.
    • Otherwise, to a broadcast address.
  • DNS resolver sets a timer.
  • If the received DNS response contains a resolved IP address for the queried domain, then it stops the timer and the segment passes the DNS resolver process.
  • If the received DNS response does not contain a resolved IP (invalid IP), it drops the segment.
  • If the DNS resolver does not receive any response packet and the timer expires:
    • DNS resolver tries to resend the query up to 5 times.
    • If the response is not received after 5 retries it gives up and sends a message to the client that it did not find any IP address for the domain name.

When a DNS server device receives a packet (flowchart here):

• If the DNS service is enabled on the device and the received packet is a DNS query:
  • If the DNS server finds a domain name in its database with the name in the query packet, it constructs the response packet with the IP address and sends it back.
  • Otherwise it sends an empty response packet back to the sender.
• Otherwise it drops the frame.

How HTTP works

When a client needs to find a webpage from a server:

• If the address is empty or starts with anything else other than http protocol it drops the request since it is not supported in Packet Tracer 5.1
• If the address is an IP address or starts with http:// the HTTP client processes it
  • The HTTP client first finds the server IP through the server name by parsing the address in the address bar and:
    • If server name is not found it tries to resolve the domain name through a DNS query.
    • If server name is found it gets the IP address.
  • The HTTP client constructs a request HTTP segment and connects the server through TCP sockets and starts a timer for its request.

When a HTTP client receives a packet (flowchart here):

• If the HTTP message has the HTTP OK code it fetches the page from the message and displays the message
• Otherwise HTTP page displays an error page.

When HTTP server receives a request (flowchart here):

• If the HTTP service is enabled and a TCP connection with HTTP client is established:
  • If the HTTP request is HTTP GET:
    • If the username and password in the HTTP request is not correct:
      • The server sends back an unauthorized error message to the client.
    • Otherwise:
      • If the requested page exists on the server:
        • The server creates a response packet and sends back a HTTP reply to the client.
      • If the requesting page does not exist on the server:
        • The server sends back an error message to the client.
  • Other message codes are not supported in this version of PT and server drops the packet.

How TFTP servers process incoming packets

When a TFTP server receives a packet (flowchart here):

• If the packet is a READ request:
  • If the file with the requested name exists on the TFTP server:
    • Start a write session with the client.
  • If the file with the requested name does not exist on the TFTP server:
    • Send back a TFTP ERROR packet to the client.
• If the packet is a WRITE request:
  • Start a read session with the client.
• If the packet is anything else:
  • Drop the packet and stop.

How TFTP servers and clients process incoming packets during a session

When a TFTP server or client receives a packet during a session (flowchart here):

• If the packet is a READ or WRITE request:
  • Drop the packet and stop.
• If the packet is a DATA packet:
  • If the session is a WRITE session or the block number on the packet is not the expecting one:
    • Drop the packet and stop.
  • Save the data on the packet.
  • Send back an ACK packet.
  • Increment the block number.
  • If this is the last packet:
    • Write data to file.
    • Stop the TFTP session.
• If the packet is an ACK packet:
  • If the session is a READ session or the block number on the packet is not the expecting one:
    • Drop the packet and stop.
  • If this is not the last packet:
    • Increment the block number.
    • Send the next block of data in a DATA packet.
  • If this is the last packet:
    • Stop the TFTP session.
• If the packet is an ERROR packet:
  • Stop the TFTP session.